IBIS Macromodel Task Group

Meeting date: 28 July 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                   Xingdong Dai
                            * Bob Miller
Cadence Design Systems:       Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC                       * David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
IBM                           Steve Parker
Intel:                      * Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                              Nicholas Tzou
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:              John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong

(Note: Agilent has changed to Keysight)

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- None
--------------------------
Call for patent disclosure:

- None
-------------
Review of ARs:

- Arpad to report to the Open Forum that ATM recommends BIRD 178 be approved in
  in the next meeting, and that it be included in IBIS 6.1.
  - Done.
  
- Mike L. to email the Open Forum to schedule the vote for BIRD 178 at the
  July 31, 2015 meeting.
  - Done.

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Curtis: I received no feedback via email for last week's minutes.
- Michael M: Motion to approve the minutes.
- Mike L: Second.
- Arpad: Anyone opposed?  [none]

-------------
New Discussion:

- Arpad: We currently have only one active topic:
  - 7: "How to handle missing min/max data?"
  - I have no updates on that topic.
- Arpad: Does anyone want to motion to untable any of the other topics?
- Michael M: Could we get a status update on each of the tabled topics?
- Arpad: We can go through the list.

Item 8:  Enforcing LTI-ness of analog models for AMI simulations.
- Arpad: I haven't heard from Scott in several weeks now.
  - I'm not sure of his intentions for this.
  
Item 9: Discuss language corrections regarding "ground".
- Arpad: We decided to table this until IBIS 6.1 is finished and approved.

Item 10: Back Channel and Optimization proposal (SiSoft).
- Arpad: This is waiting for feedback from Cadence.
  - Ambrish communicated that he was unable to attend today and hadn't yet made
    any progress on gathering the feedback.
    
Item 11: BIRD 147.1 and co-optimization (Cadence).
- Arpad: I separated this from item 10 because we have an official BIRD 147
         from Cadence and Walter had given an independent proposal.

Item 12: New Redriver flow BIRD.
- Walter: I have no new progress to report.
  - I'm not sure if we need that BIRD and will await Fangyi and others.
  - I found a clear error in the flow in the spec under certain circumstances.
  - I came up with a new flow.
  - Do we need it as a BIRD?  I don't know.
- Arpad: If there's a new flow, shouldn't the spec say something about it?
- Walter: Not if we just consider it a reference flow.
- Arpad: I'm concerned about that if all EDA vendors can do whatever they wish.
- Walter: The people writing these models make them based on the flow I defined
          in the BIRD. Model makers are doing it that way.
- Arpad: There's a flow in the spec and a flow in the BIRD.
  - The flow in the BIRD needs to be approved or rejected.
- Walter: The BIRD is there now.
  - If it gets approved, that's fine.
  - I don't want to put more effort into pursuing that approval.
- Radek: The BIRD doesn't solve all the issues, particularly if you have a chain
         of repeaters.
  - The question is whether there should be some guidelines related to some of
    the specific cases, so people understand them and know how to write models,
    as Walter said.
- Bob: We need to discuss this further.
  - If the flow in the spec is wrong, then we have a problem.
- Walter: To answer Arpad's original question:
  - SiSoft is prepared to have those discussions, but I'm not going to actively
    pursue the BIRD's approval.
  - Someone else may want to pursue it with modifications like Radek suggested.
- Arpad: I believe that when we left it Walter and Fangyi were supposed to have
         a discussion on what should be in the BIRD.
- Walter: We did not have those final discussions.
  - We got involved in other important things.
  - This wasn't my highest priority.
  - SiSoft is happy, but if others want it in the spec that's fine.
  - Radek wants more in the BIRD, so I'll defer.
- Arpad: I would like to bring it to a close.
  - What's the next step?
  - Should Radek and Fangyi come back with more suggestions?
- Radek: Yes, we can try to look at it.  People are busy.
  - The issue is likely that things get too complex in certain scenarios.
- Arpad: To answer Michael's original question, this BIRD is indefinitely
         tabled until people free up.

Item 13: C_comp improvements.
- Randy: This is waiting until the interconnect proposal is finished.
  - Much of this depends on the language in the interconnect proposal.

Item 14: BIRD 128.
- Radek: I was against the idea of BIRD 128.
  - I've often said I would rather have a separate API rather than hacking the
    existing GetWave() functionality.
  - I would be happy to fold a separate API into BIRD 147 or SiSoft's proposal.
  - I don't see a future for BIRD 128.
- Walter: I worked very hard to make the backchannel proposals I did compatible 
          with BIRD 128.
  - BIRD 128 was what Cadence and SiSoft did when we started this years ago.
  - I'd be willing to accept your proposal to drop BIRD 128.
  - Then we could just move ahead with my proposal.
  - We already have an API for a new Init() and we can add one for GetWave().
  - It would be easy to update my proposals with a new API for GetWave().
  - We could adopt my proposal for replacing BIRD 147.  It does everything
    Cadence wants and everything everyone else wants.
- Arpad: Will you formalize a BIRD?
- Walter: I made the presentation.
  - If this group wants to move forward, I'd be happy to write up a BIRD.
  - Giving up being compatible with BIRD 147 would simplify it.
- Radek: I think the idea was that Ambrish was supposed to come back with
         some feedback, but we haven't seen it yet.
- Walter: Ambrish said their IC people aren't pushing them.
  - Doesn't sound like that feedback is going to happen.
- Arpad: It has been over six months now.
  - How long do people feel we should wait for the feedback?
  - I don't want this wait period to stall progress.

Item 15: Info, Out, InOut BIRD.
- Arpad: This is ancient.  I think we've had two new revisions of the spec
         since this topic came up.
  - I will take the AR: to see if it's even valid anymore.

Item 16: DLL error trapping and return codes.
- Arpad:  Greg's proposal is also ancient.
- Michael M: Is this in part being addressed by the quality task group and
             some .dll checking they were discussing?
- Radek: It was partially addressed by some other BIRDs.
- Arpad: A similar topic was on the reflector a few months ago.
- Mike L: Greg was talking about the generic finger pointing problem.
  - Michael M. was referring to efforts to come up with a tool that does a
    little bit of inspection.
  - It has come up in the Open forum recently, too.
  - Hard to see us making too much progress.
  - It would involve a fair amount of code development.
- Michael M: Someone on this call [David] has developed a free probing utility.
  - .dlls aren't totally opaque.
    - Are certain functions present?
    - Are they at least minimally conforming to expectations?
  - Does the existence of this tool address Greg's problems?
  - Do we need to put that in the official parser?
- Arpad: We have had discussions in the past about the parser checking the .dll.
  - Should I send an email to Greg?
- Michael M: I motion that Arpad email Greg.
- David: Second.
- Arpad: Anyone opposed? [none]
- Mike L: In one of the quality meetings we presented a list of checks that
          could be done.
  - We could schedule to look at that in one of the ATM meetings.
- Arpad: I was thinking the opposite. Perhaps quality could take this?
- Mike L: Quality usually consists of Bob and Lance and myself.
  - Even if we were to do this in the parser, or python, etc., it helps to
    start with a spec for what we want to do.
- Arpad: When do you want me to schedule it in this group?
- Mike L: Next week would work.
- Arpad: I'll email Greg and we can decide depending on his response.

Item 17: Macro models for power delivery.
- Walter: I was saying you can represent the time dependence of a power supply
          with spectral density.
  - Therefore, handle power variations either statistically or that spectral
    content can generate a power waveform.
  - No one has gotten excited about it, so we can remove this from the list.
- Arpad: Is this useable for AMI purposes?
- Walter: It could be used for AMI purposes.  Rail voltage has direct frequency
          content on amplitude noise of the generated signal.
- Arpad: I ask because that time varying waveform would violate LTI.
- Walter: For statistical processing you'd do things like adding sinusoidal
          jitter.
  - For example, if you knew there was a lot of energy around 50MHz, then you'd
    put in sinusoidal jitter at 50MHz.
- Arpad: Could this statistical approach for describing power supplies be
         translated into modifying the impulse response itself?
- Walter: You could just modify the input waveform passed into Tx GetWave() and
          document that it's now really an analog signal not a digital signal.
- Arpad: Should this topic be left on the list?
- Walter: Unless someone says they have a problem to solve, let's remove it.
- Arpad: I will take this off the list.

New PAM4 Parameters Question:
- Arpad: There are two PAM4 parameters, thresholds and offsets, that are In, Out,
    or InOut.
  - So the model could return new values for these from GetWave().
  - If the model can return those values, are they supposed to be used real-time
    as the EDA tool generates the eye?
  - Do we have rules on when the values can be changed or returned?
  - Does it make sense for the models to return those values instead of having
    them in the AMI file?
- Walter: Yes.
  - In practice, after a certain number of ignore bits are processed, the timing
    offsets and thresholds settle out and those are the ones that you use.  They
    might change from call to call.
  - The EDA tool can accumulate that information as it sees fit.
- Arpad: So should the EDA tool process the eye using the values from one 
         GetWave() call to the next?
- Walter: EDA tools can do creative things and differentiate themselves.
  - IBIS should just describe a model and what it returns.
- Arpad: So the answer to my question is, "yes, it makes sense for the model to
         return the values."
- Arpad: Any other discussions for today's meeting? [none]
  - Thank you all for joining.
  
AR: Arpad to investigate the current relevance of tabled item 15.
AR: Arpad to email Greg Edlund to ask about his current thoughts on his DLL error
    trapping topic (item 16).

-------------
Next meeting: 4 August 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
